Hi, I had a look into this before the last official version and was able to reproduce the issue but we were out of time and I couldn't think of a quick solution. As far as I can understand, the trouble is that the mouse wheel cannot be 'held down' like an ordinary gearshift key or button. It is only 'held down' for such a short time (I think it was a set number of physics frames, or maybe only 1 frame) that the engine may not be sufficiently unloaded to allow the shift at that moment. I'm not really sure what the solution should be. Maybe it needs special code when a mouse wheel is assigned to shifting, so that instead of doing the normal thing (holding down a fake button/key for a set number of frames) it should do some sort of semi-intelligent thing like holding down a fake key until a gear change has occurred, but for a maximum of 1 second, or something like that.
Just to explain another way in case my text above made no sense - for clutchless upshifts you are really supposed to hold the upshift key/button on, then release the throttle momentarily, and at that point you release the upshift key/button. The mouse wheel as it is currently coded is not suitable for this as there is no concept of "holding the button on".
Just to explain another way in case my text above made no sense - for clutchless upshifts you are really supposed to hold the upshift key/button on, then release the throttle momentarily, and at that point you release the upshift key/button. The mouse wheel as it is currently coded is not suitable for this as there is no concept of "holding the button on".
I made a step forward in tyre physics last week. Although there is still a lot to do, I thought it would be good to try a test of the 1000Hz updates this week (nothing to do with tyre physics but may help with separating physics and graphics onto separate threads, along with other advantages). I was able to get a first version running in a day and worked another day searching through references to 'turns' and fixing various issues where the code had assumed that each turn was 0.01s. Now it's coded in a flexible way so I can change the update rate and recompile, to get comparisons between the 100Hz and 1000Hz versions. Actually there's a bit more searching to do but I was able to run some tests.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
The good results:
The moving image is noticeably smoother. Different people have a different sensitivity to the stutter that results from the mismatch between graphical frame rate and physical update rate. As mentioned before, with a 60Hz frame rate and 100Hz physics rate, the graphical frames have physics updates like this: 2, 2, 1, 2, 2, 1...
This is known to be a worse problem in VR, with 90Hz frame rate, there are 8 graphical frames with 1 physics update, then the 9th graphical frame has 2 physics updates. So there is an extra step 10 times every second which is unpleasant when you look left or right out of your car and see scenery moving by.
That stutter can be reproduced without VR by a simple camera movement test. In full screen with vertical sync enabled, park a car in the open (e.g. at autocross) enter free view mode and look down at the car. Use left mouse button to move the car in circles or from left to right. You can see a sort of stutter or blurring at the edges of the car, or with the paint lines on the road.
With the 1000Hz version, the physics updates per graphical frame are 17, 17, 16, 17, 17, 16... which seems a lot smoother and the stutter is no longer noticeable.
Also super slow motion looked nice. Even when slowed to 1/8 speed, the physics frame rate is still 125 Hz which is more than the frame rate, so the slow motion car looks smooth.
Physics checks with the environment are more frequent, for example at 100mph we are at about 45m/s so with 100Hz updates, environment checks are every 45cm. With 1000Hz updates the environment checks are every 4.5cm. This looked good in force view as the AI driver's wheels drove over the kerbs though I have not tested FF. I don't expect to feel a difference but it could be good for people with high end DD wheels.
The bad results:
So far the CPU usage is too high. I ran a test with 10 AI cars at the start line in South City. As expected the environment checks used 10 times the CPU. The movement update also took more CPU time due to not being in a tight loop (although there are the same number of movement updates, known as sub-updates in the 100Hz version). This is assumed to be related to the cache. It's more efficient when the CPU runs a tight loop on the same data, compared with going through all the other cars and then going through all sorts of other code and data before coming back to the same data again the next frame.
Results when changing from 100Hz to 1000Hz:
10 cars on grid at new South City, physics code % of CPU time
environment checks - 2.2 up to 20.3
movement update - 3.9 up to 9.40
What next:
The movement update may be improved a little because there are no actual sub-updates, some things could be done more efficiently but I do not expect a very significant improvement.
The environment check CPU time increase is not acceptable. This 20% CPU usage is only with 10 cars and it gets far worse when the cars go through the underpass. But nearly all these environment checks are actually parts of the car (contact points and wheels) checking for collisions with nearby objects and not getting a collision at all. This suggests there is a lot of scope for optimisation. The idea is to avoid the detailed collision check in most cases if there isn't any chance of a collision. Of course, this is done to some extent already but a more accurate method is needed. The first thing to try is "Oriented Bounding Boxes" for the track segments. It's the obvious choice as it could reduce a lot of checking against fences, barriers and road surfaces. I'll need to try that and see how it goes before trying to think of other types of optimisation.
Good question but the answer is quite unknown at the moment.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.
In fact it's not really 10 times the workload, although there is certainly more workload. The current LFS does 'subupdates' within the physics updates. The main reason for that is the wheel object suspended between a strong spring pushing down (suspension) and another stiff spring pushing up, the physics needed a higher update rate to avoid instability in that and I think on some other areas too.
In the public version that subupdate rate is 20 times the overall physics rate. So there is a part of the car already updating at 2000 Hz. In the development version there are 10 subupdates so it's already running at 1000 Hz.
But the ray checks vs world objects (and other cars) only happen at the base physics rate, so that is only at 100 Hz. This part might be 10 times the workload, as you suggest. There is also an advantage in the existing version that the subupdates are done as a tight loop on an individual car so I assume this is good for cache access. I'm sure that expanding the tight subupdate loop into full physics frame loops will be less efficient for cache hits.
Diagram:
Current:
0.00 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
0.01 - Environment check for all cars
Physics update for car 1 (10 subupdates)
Physics update for car 2 (10 subupdates)
...
[0.02s elapsed]
Proposed:
0.000 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
0.001 - Environment check for all cars
Physics update for car 1 (1 subupdate)
Physics update for car 2 (1 subupdate)
...
[0.002s elapsed]
I really can't guess how much more work this would be. The environment checks may be 10 times, as you pointed out. I think some optimisations might help with this. The subupdates shouldn't cost any more calculations but presumably will be slowed by memory access as the 'subupdates' are no longer done on a tight loop for a single car.
I think the way forward is to go through the program, adjusting it where necessary so that I can test the two scenarios above with a simple program change (update frequency & number of subupdates). Then test the CPU usage for the physics loop and see how it compares. That sounds simple but as you may imagine, I haven't always put in a suitable multiplier when trying to work quickly to release updates. There is some code around like "do this for 100 updates" which I knew would take 1 second. But now such code needs to be changed to the equivalent of "do this for 1/update_time updates" etc. It shouldn't take too long to get for a first test just to see how the CPU usage is affected. Hopefully it's just a search for the word "turns" and look at each one to see if it needs a fix.
The word "turns" (not case sensitive) appears 671 times
The word "Turn" (case sensitive) appears 785 times
Unfortunately the word "turn" in lower case is part of the word "return" which appears 9687 times.
But don't worry, I should be able to devise reasonable strategies to find the relevant lines to check.
Last edited by Scawen, .
I kept thinking though. Remembered there may be a good "sledgehammer to crack a nut" type solution. This would be, for the snapshots, store a FULL copy of all the car variables (using direct copies of the entire car and wheel structures). These snapshots can be *written* by the physics system and *read* by the graphics system, but are created without too much brain power, just copy everything. Well, not *everything* for example you wouldn't copy the mesh from one frame to the next. So even this sledgehammer style "copy a snapshot of car" function would need some care and there is always the complication of things like, player spectates car, so car is deleted. But graphics system is still in the process of rendering the car -> crash or mysterious errors.
Some design considerations might cause quite a change. For example, the current physics frames are at 100 Hz. So to render at 60 Hz or any other frame rate, the graphical frames should be an interpolation between two physics frames. This would solve a well known problem that is particularly bad in VR. But there is an alternative solution - do physics frames at 1000 Hz instead of 100 Hz. Then store only the snapshots for the relevant physics frames and render only the nearest physics frame, not interpolated.
For example, with physics at 1000 Hz, rendering at 60 Hz graphically, we could use physics frames with gaps (in ms):
16, 17, 17, 16, 17, 17 (that represents 6 graphical frames in 0.1s).
I don't know if this slight difference between frame times would be humanly perceptible, though I'm sure it would be a lot smoother than any current version of LFS. For example, current LFS rendered at 60 Hz has gaps (in ms):
10, 20, 20, 10, 20, 20 (6 graphical frames in 0.1s).
Anyway, as I said, it's an interesting subject.
But I don't have to think about that now, it's not tyre physics.
Some design considerations might cause quite a change. For example, the current physics frames are at 100 Hz. So to render at 60 Hz or any other frame rate, the graphical frames should be an interpolation between two physics frames. This would solve a well known problem that is particularly bad in VR. But there is an alternative solution - do physics frames at 1000 Hz instead of 100 Hz. Then store only the snapshots for the relevant physics frames and render only the nearest physics frame, not interpolated.
For example, with physics at 1000 Hz, rendering at 60 Hz graphically, we could use physics frames with gaps (in ms):
16, 17, 17, 16, 17, 17 (that represents 6 graphical frames in 0.1s).
I don't know if this slight difference between frame times would be humanly perceptible, though I'm sure it would be a lot smoother than any current version of LFS. For example, current LFS rendered at 60 Hz has gaps (in ms):
10, 20, 20, 10, 20, 20 (6 graphical frames in 0.1s).
Anyway, as I said, it's an interesting subject.
But I don't have to think about that now, it's not tyre physics.
Last edited by Scawen, .
Reason : typo
I'd still like to do that (physics and graphics on separate threads so they can be processed simultaneously by different CPU cores) but I'll reconsider when the tyre physics seems acceptable. I wouldn't like to delay the release purely for that but it might be important for performance reasons. The new LFS does a lot more CPU work for the graphics. Although the GPU does most of the work, the CPU needs to make a lot of decisions about which objects to draw into the shadow maps. The CPU must instruct the GPU and it would be great if that graphics could use a separate CPU core so it doesn't need to share a single core with the physics.
The trouble with that (as I see it) is the separation of the cars (and other graphical elements, like skids, dust, etc) into a physical part and a graphical part. At the moment a car and its wheels have graphical and physical things all mixed in together without a clear separation. Some variables are purely physical, some purely graphical, some are shared between both. There needs to be a very good separation so the physics can continue to proceed, adjusting the car's state such as suspension, wheel rotation, body position, while the graphics system can render all the cars for one particular physics frame (or an interpolation of physics frames). It cannot simply render a car that might be half updated, part way through a physics frame. So before or after each physics frame is calculated, a 'snapshot' of each car must be stored, with enough variables to render every aspect of that car.
Because a car contains hundreds of variables, it's not a simple task to create that snapshot system, where a clearly separated graphics system reads only the snapshots, without access to the car variables that it always used in the past.
It sounds like a really interesting programming task though, but is quite a lot of work do do, as I am reminded when I look through the car and wheel structure definitions.
The trouble with that (as I see it) is the separation of the cars (and other graphical elements, like skids, dust, etc) into a physical part and a graphical part. At the moment a car and its wheels have graphical and physical things all mixed in together without a clear separation. Some variables are purely physical, some purely graphical, some are shared between both. There needs to be a very good separation so the physics can continue to proceed, adjusting the car's state such as suspension, wheel rotation, body position, while the graphics system can render all the cars for one particular physics frame (or an interpolation of physics frames). It cannot simply render a car that might be half updated, part way through a physics frame. So before or after each physics frame is calculated, a 'snapshot' of each car must be stored, with enough variables to render every aspect of that car.
Because a car contains hundreds of variables, it's not a simple task to create that snapshot system, where a clearly separated graphics system reads only the snapshots, without access to the car variables that it always used in the past.
It sounds like a really interesting programming task though, but is quite a lot of work do do, as I am reminded when I look through the car and wheel structure definitions.
I've said before but will explain again as I know not everyone would know this:
The old tyre physics does not exist in the new version of LFS. Too many things were changed - the way the tyres work, the specification of the tyre compounds, the AI drivers, various abstract things, etc. At some point I found it impossible to keep two versions of tyre physics in the one program. There is no file "TyrePhysics.cpp" or something like that. Contributions to the tyre physics are spread around many files and systems within the game code.
So it would be a lot of work to bring the old tyre physics back into the new version of LFS. It's a possible option but would be madness to do that right now. Going back into the past, and making myself suffer for no reason at all.
What seems the right thing to do is try to make the new tyre physics work properly, then all's good and we move into a new era graphically and physically. Anyway Eric still has work to do on various tracks so it's not as if we are just waiting for me. Eric is of course free to comment if he wants to but I don't want to bother him for a graphical progress report at this time. My focus is the tyre physics and that's all really.
The old tyre physics does not exist in the new version of LFS. Too many things were changed - the way the tyres work, the specification of the tyre compounds, the AI drivers, various abstract things, etc. At some point I found it impossible to keep two versions of tyre physics in the one program. There is no file "TyrePhysics.cpp" or something like that. Contributions to the tyre physics are spread around many files and systems within the game code.
So it would be a lot of work to bring the old tyre physics back into the new version of LFS. It's a possible option but would be madness to do that right now. Going back into the past, and making myself suffer for no reason at all.
What seems the right thing to do is try to make the new tyre physics work properly, then all's good and we move into a new era graphically and physically. Anyway Eric still has work to do on various tracks so it's not as if we are just waiting for me. Eric is of course free to comment if he wants to but I don't want to bother him for a graphical progress report at this time. My focus is the tyre physics and that's all really.
I'm just working on the tyre physics, researching, testing, becoming familiar with the new tyre model again and looking at how to make sure it behaves like real tyres.
I just need peace of mind to keep working on that. When the tyre physics is done then we will be in a state to consider how to get to a release of the new version of LFS.
That's all I know.
I just need peace of mind to keep working on that. When the tyre physics is done then we will be in a state to consider how to get to a release of the new version of LFS.
That's all I know.
That is not possible, because that system has been removed in the later version of physics. As the editor is built in the new development version, that option has already gone.
I think it must be that the points are used by a triangle.
You can use "select connected triangles" to find the triangles. Note that the triangles may be in a different LOD, because points are shared between levels of detail. So you may need to "select connected triangles" again in each LOD.
My plan is to get stuck into the tyre physics. The new tyre physics system is in the development version with the new D3D11 graphics system. So if I can get the tyre physics to a releasable state, then we'll be very close to releasing the graphical update (with the tyre physics). I can't give any time estimates but that is what I intend to focus on for now.
There are a lot of good suggestions for more improvements in the mods system, but it will be easier to develop such things in future when I only have one version of code to maintain.
There are a lot of good suggestions for more improvements in the mods system, but it will be easier to develop such things in future when I only have one version of code to maintain.
Well... it would be a lot easier than the current stereoscopic 3D mirror system! But it would be quite a system, with some new features like the ability to set camera positions and field of view, etc. I know a lot of people want this feature and I would like to do it, but it's another other of those things that is harder to do right now as all the changes would have to be done in both the current version and the development version. So at this point it's best to get on with the tyre physics so we can get back to a single version.
I've updated the editor to a new B12 version. It's a minor update - really just a test after merging all the recent LFS updates.
Text entry system language support was improved in LFS
Better alignment of entry screen buttons
Smaller LFS logo on entry screen
https://www.lfs.net/forum/thread/97865
You can set that in Options... Display... Interface - Opacity (below 'Big Button' colour)
I've uploaded a new test patch B12, with minor updates. I've started looking into the tyre physics again. At this point I would like to release a full version with the latest changes from the test patches.
B12 has a fix and an option and all the recent changes have been fully merged with the development version. That is quite a big operation and always involves a few lines being changed, so it's worth testing. Also translations have been updated.
Command /eventlist=no to disable list of events
Corrected opacity of background buttons in mods screen
Can receive one more text field to show beside "Sign up"
Updated translations - thank you translators!
https://www.lfs.net/forum/thread/97772
I have no idea about this and no plans to code something like that. My sole aim is to get back onto the tyre physics so we can release the new graphics and physics systems.
But I assume from what you say, that LFS Lazy can show a buddy list on the main entry screen. I've now made sure that the Calendar is not displayed at all if there are any InSim buttons in the so-called "recommended area" that covers most of the left side of the screen.
Doom and gloom won't help anything.
Also talking about Steam is way too irrelevant.
This thread was about a couple of quick changes we could do, to help with participation while we finish the new tyre physics and graphics system.
It's way too off topic now (and weirdly doomist - totally unhelpful NumberTwo). So I'll close the thread for now and reply later with the mockup for the calendar on entry screen.
Also talking about Steam is way too irrelevant.
This thread was about a couple of quick changes we could do, to help with participation while we finish the new tyre physics and graphics system.
It's way too off topic now (and weirdly doomist - totally unhelpful NumberTwo). So I'll close the thread for now and reply later with the mockup for the calendar on entry screen.
Yes, these graphs have not escaped my attention. The good bit is the right hand side on the licensed racers. It's a big increase over recent years, due to mods of course. And the new graphics and physics will be another good boost.
But I was really wondering if there was anything we could do, quite quickly, to boost participation, including this well organised and fun rallycross event you are running. Tyre physics and graphics update of course aren't an immediate solution.
Well you are wrong about that because the graphics update is far more recent than that.
If we are going to talk about what was promised when, then the conversation isn't going to get very far.
If you read the first post, I was wondering if there was anything we could do to improve attendance in the current version, and I specifically asked to avoid a discussion about the graphics and physics, which I acknowledged already as what I need to do on my side.
How to improve attendance for scheduled events?
[ EDIT: This thread is from March 2022. Changes have been made but questions still remain.
New posts in 2023: https://www.lfs.net/forum/post/2033558#post2033558 ]
Hello Racers,
I watched the Rallycross event yesterday, it's a really well done race with interesting layouts, short races and joker laps. There are heats and finals. It would be a great race for people who aren't the top racers, as with 3 to 4 lap races you won't end up being lapped or getting in the way. You could just blast around and have fun. The event is live streamed and basically has everything going for it.
Round 1 was great but there were only 11 racers.
Yesterday's event, round 2 only had 7 drivers!
Some other (different) events have had to be cancelled or toned down due to lack of participation.
So what's up?
1) Do people not know about these events? They are on the LFS calendar and we always tweet the weekly calendar that Mandula makes. Of course not everyone has twitter and not everyone looks at the calendar.
2) Do racers know about it but don't want to enter? Aren't interested in showing up at a specific time? Are they worried about getting in people's way? What other reasons for non-participation?
3) Or is it something technical, like they know about races, would like to enter but have difficulty finding out the information and rules?
I'd be really interested in what you have to say, and if there's some way we can help, maybe through the website or the forum. I know that on my side I need to get the tyre physics done so we can release the new tracks. But please can we leave that sort of thing out of the discussion? As LFS is already capable of providing interesting and varied races. I'm more interested in knowing if there is something we can do to help the participation in the existing version.
New posts in 2023: https://www.lfs.net/forum/post/2033558#post2033558 ]
Hello Racers,
I watched the Rallycross event yesterday, it's a really well done race with interesting layouts, short races and joker laps. There are heats and finals. It would be a great race for people who aren't the top racers, as with 3 to 4 lap races you won't end up being lapped or getting in the way. You could just blast around and have fun. The event is live streamed and basically has everything going for it.
Round 1 was great but there were only 11 racers.
Yesterday's event, round 2 only had 7 drivers!
Some other (different) events have had to be cancelled or toned down due to lack of participation.
So what's up?
1) Do people not know about these events? They are on the LFS calendar and we always tweet the weekly calendar that Mandula makes. Of course not everyone has twitter and not everyone looks at the calendar.
2) Do racers know about it but don't want to enter? Aren't interested in showing up at a specific time? Are they worried about getting in people's way? What other reasons for non-participation?
3) Or is it something technical, like they know about races, would like to enter but have difficulty finding out the information and rules?
I'd be really interested in what you have to say, and if there's some way we can help, maybe through the website or the forum. I know that on my side I need to get the tyre physics done so we can release the new tracks. But please can we leave that sort of thing out of the discussion? As LFS is already capable of providing interesting and varied races. I'm more interested in knowing if there is something we can do to help the participation in the existing version.
Last edited by Scawen, .
I recommend use of the latest editor. It contains a check for the bug that can cause a side texture to change sides in LFS and can also result in the mesh going crazy after a collision: https://www.lfs.net/forum/thread/97865
But that doesn't explain the reversed mappings in LOD2 that Gutholz has mentioned.
As Gutholz says, it is best to correctly assign LOD2 and LOD3 triangles to the correct mapping. For example, assign the side triangles to the side mapping from LOD1, and assign up-facing triangles to the top mapping, etc. Although the shape of a physics mesh cannot perfectly align with your texture, it is only seen at a distance and the change to LOD3, even with slightly odd mappings, is much less noticeable than a total colour change. This is really easy to do for the physics LOD as it only contains a few triangles.
But that doesn't explain the reversed mappings in LOD2 that Gutholz has mentioned.
As Gutholz says, it is best to correctly assign LOD2 and LOD3 triangles to the correct mapping. For example, assign the side triangles to the side mapping from LOD1, and assign up-facing triangles to the top mapping, etc. Although the shape of a physics mesh cannot perfectly align with your texture, it is only seen at a distance and the change to LOD3, even with slightly odd mappings, is much less noticeable than a total colour change. This is really easy to do for the physics LOD as it only contains a few triangles.
I just want to be clear that nearly all the car models were made by Eric.
I only made the UF model. I know it needs some updates.
But I was involved with the physics of all the cars.
Thanks for the feedback.
I don't expect everyone to read my long post, but it is quite amusing that my post said, in short, "I want to stop working on mods for now" but quite a few people have taken it as a request for mod-related suggestions. The exact opposite of what I said!
Sorry but these suggestions won't happen now! I'm trying to stop working on mods now, so I'm just fixing a few important things, and leaving a lot of things that *could* be done, on a list for the future.
I really would like to hear from anyone who has seen this bug, I'd like to have an example replay with this problem so I can find out what causes this bug.
It's a good suggestion but that won't be done now. As mentioned before, I want to finish the updated tyre physics so we can release the new graphics version.
I don't think we'll ever support translations for mod descriptions. It would really be too difficult to manage such a system.
Fixed setups might be interesting. But as for all the suggestions, it'll be a whole lot easier to imlpemet new ideas when I only have to implement them into one version instead of two, so that's why I'm trying to stop working on mods now.
No the viewer isn't visible in VR. It would be cool to see the 3D car there but such a system doesn't exist and as with all these things, very hard to have to implement it into two separate versions of LFS. The garage car in VR is like an image, it is drawn flat onto a texture so it works in VR but that is not the case for the viewer.
You can see the virtual keyboard when searching for mods if you press the virtual keyboard button on your controller. If using mouse you'd better press backspace before clicking the search field.
This is probably impractical and certainly will not be done now. At least it's really easy to get to the web page by clicking a link in-game.
OK everyone, I only really want to hear about bugs or issues now. No suggestions please. There is a separate suggestions thread.
I don't expect everyone to read my long post, but it is quite amusing that my post said, in short, "I want to stop working on mods for now" but quite a few people have taken it as a request for mod-related suggestions. The exact opposite of what I said!
Sorry but these suggestions won't happen now! I'm trying to stop working on mods now, so I'm just fixing a few important things, and leaving a lot of things that *could* be done, on a list for the future.
I really would like to hear from anyone who has seen this bug, I'd like to have an example replay with this problem so I can find out what causes this bug.
It's a good suggestion but that won't be done now. As mentioned before, I want to finish the updated tyre physics so we can release the new graphics version.
I don't think we'll ever support translations for mod descriptions. It would really be too difficult to manage such a system.
Fixed setups might be interesting. But as for all the suggestions, it'll be a whole lot easier to imlpemet new ideas when I only have to implement them into one version instead of two, so that's why I'm trying to stop working on mods now.
No the viewer isn't visible in VR. It would be cool to see the 3D car there but such a system doesn't exist and as with all these things, very hard to have to implement it into two separate versions of LFS. The garage car in VR is like an image, it is drawn flat onto a texture so it works in VR but that is not the case for the viewer.
You can see the virtual keyboard when searching for mods if you press the virtual keyboard button on your controller. If using mouse you'd better press backspace before clicking the search field.
This is probably impractical and certainly will not be done now. At least it's really easy to get to the web page by clicking a link in-game.
OK everyone, I only really want to hear about bugs or issues now. No suggestions please. There is a separate suggestions thread.
Well... seeing as you are interested... it might be helpful for people to understand the thinking behind the patch, some info about how things actually go in the real world as opposed to some imagined perfect world where I can continue coding full time without any issue. And what the plans are as I see them.
Since version B was released, first I did some finishing work that week and put a little time into a special version that can really help with events such as the football (Soccar) event. As the ball can run on the host, it works so much better. It's a special server version that could be used for some special cases in future. Something I really wanted to do, even since before the first public version of mods. It's an interesting concept. The reason I even *do* this job, is so that I can follow interesting concepts and get them done!
Then I got Covid, and it was the kids half term. So not much done that week.
As you know, we have a public review system now, and it has been fairly common for people to submit mods from other games, usually by mistake (e.g. they got it from a supposedly legitimate website but the person who uploaded it there didn't actually make it). We can't host such mods, so it's important to have the wireframe view that helps people to examine the model and see if it has come from an illegitimate source.
I don't like the fact that there was a crash in the version. Even if rare... there's one reason that LFS doesn't crash much. It's not because it's 'old' or 'can run on a toaster' etc. It's because I always try to fix every crash, and respond when community members report one.
A couple of other bugs and issues were spotted in the football event so I did a quick fix for them. The shadow bug and the wall riding. Good to fix them. Then when fixed, why hold them back? You guys can have the fix too!
One important thing, for people with worse internet connections, is the ability to download mods while joining a host, instead of after you have joined. It was on my sheet for months, long before the first public test patch of the mods system was ever released. I actually did that in a day yesterday. It has been a little hard to get right back to work after Covid.
Although my Covid was classed as 'mild' I can tell you that for me it was a lot worse than a normal cold. I had some rough nights, weird aching muscles and all sorts of symptoms, separately and sequentially. For info I'm 50 years old and semi-fit meaning I run and ride bikes a bit and walk a few km nearly every day if I don't run or ride. I eat a healthy diet, do not smoke (for 10 years) and rarely drink (and if I do, it's one glass). I actually thought Covid would hit me less hard. As I work from home, I was not vaccinated. I got the Covid from Leo who brought it back from school. I'm not asking for sympathy, it was my choice. I have my reasons.
So the download mods thing was a real good day of work yesterday. I had been somewhat distracted by the war and programming seemed very confusing. It's hard to explain to a non-programmer, quite how hard programming can be and how organised you have to be and have a good short term memory and sometimes keep notes as you go. Even in this case, when I wasn't really doing something entirely new and inspirational, there's data collection, packet sending, list processing, and it's quite simply a lot more involved than you might imagine!
I want to call a stop to working on mods, as you know, with a solid version out there. So that's what this test patch is all about. A simple update that allows me to get on with the tyre physics. There are a lot more things I could do with mods but I want to stop, because when we get the new physics and graphics out, it'll be easier to work on things as I won't have to merge two separate versions.
Since version B was released, first I did some finishing work that week and put a little time into a special version that can really help with events such as the football (Soccar) event. As the ball can run on the host, it works so much better. It's a special server version that could be used for some special cases in future. Something I really wanted to do, even since before the first public version of mods. It's an interesting concept. The reason I even *do* this job, is so that I can follow interesting concepts and get them done!
Then I got Covid, and it was the kids half term. So not much done that week.
As you know, we have a public review system now, and it has been fairly common for people to submit mods from other games, usually by mistake (e.g. they got it from a supposedly legitimate website but the person who uploaded it there didn't actually make it). We can't host such mods, so it's important to have the wireframe view that helps people to examine the model and see if it has come from an illegitimate source.
I don't like the fact that there was a crash in the version. Even if rare... there's one reason that LFS doesn't crash much. It's not because it's 'old' or 'can run on a toaster' etc. It's because I always try to fix every crash, and respond when community members report one.
A couple of other bugs and issues were spotted in the football event so I did a quick fix for them. The shadow bug and the wall riding. Good to fix them. Then when fixed, why hold them back? You guys can have the fix too!
One important thing, for people with worse internet connections, is the ability to download mods while joining a host, instead of after you have joined. It was on my sheet for months, long before the first public test patch of the mods system was ever released. I actually did that in a day yesterday. It has been a little hard to get right back to work after Covid.
Although my Covid was classed as 'mild' I can tell you that for me it was a lot worse than a normal cold. I had some rough nights, weird aching muscles and all sorts of symptoms, separately and sequentially. For info I'm 50 years old and semi-fit meaning I run and ride bikes a bit and walk a few km nearly every day if I don't run or ride. I eat a healthy diet, do not smoke (for 10 years) and rarely drink (and if I do, it's one glass). I actually thought Covid would hit me less hard. As I work from home, I was not vaccinated. I got the Covid from Leo who brought it back from school. I'm not asking for sympathy, it was my choice. I have my reasons.
So the download mods thing was a real good day of work yesterday. I had been somewhat distracted by the war and programming seemed very confusing. It's hard to explain to a non-programmer, quite how hard programming can be and how organised you have to be and have a good short term memory and sometimes keep notes as you go. Even in this case, when I wasn't really doing something entirely new and inspirational, there's data collection, packet sending, list processing, and it's quite simply a lot more involved than you might imagine!
I want to call a stop to working on mods, as you know, with a solid version out there. So that's what this test patch is all about. A simple update that allows me to get on with the tyre physics. There are a lot more things I could do with mods but I want to stop, because when we get the new physics and graphics out, it'll be easier to work on things as I won't have to merge two separate versions.
Thank you all for the testing and feedback!
Version 0.7B is now available. https://www.lfs.net/forum/thread/97376
I made a note of these requests. It was important to get 0.7B out as soon as possible, for all the fixes and to support the new public review system. I still have quite a few things on paper here, both compatible and incompatible things. I'll be considering them to see if we need one more patch on the mods subject before I get stuck into the tyre physics.
Version 0.7B is now available. https://www.lfs.net/forum/thread/97376
I made a note of these requests. It was important to get 0.7B out as soon as possible, for all the fixes and to support the new public review system. I still have quite a few things on paper here, both compatible and incompatible things. I'll be considering them to see if we need one more patch on the mods subject before I get stuck into the tyre physics.
Thanks, yes I am really looking forward to releasing the new physics and graphics.
One of the worst things for me is that any changes I do in the public version, I have to copy to the development version. So after any heavy session of coding, there is a lot of code merging as well. It feels like driving with the brakes on or swimming with a parachute. I am so slowed by this awful situation of maintaining two different but similar code bases.
I obviously did not know many years ago, when I separated it into two versions, that there would be MANY updates in the public version. It wasn't a situation I took lightly, it was becoming too hard to keep two versions of physics in the same code. But I had known the future, I would have taken a different decision.
So I'm looking forward to that chapter of my life to be over. It really makes it hard to add anything new and major, because there is so much code merging to be done.
I don't have a plan for that as my main focus is to release what we have as an official version ASAP (early in the week). As always, there are a lot of things (maybe hundreds) that are important to different people but I can't do many of them, as each small thing takes a long time.
I really have to stop working on the mods, so I can sort out the tyre physics and then we can release the new graphics. So there has to be an end. And I still have a couple of important things on my list.
Anyway, is there an appropriate InSim packet that your requested data values could be squeezed into? It's always a lot easier to use some unused bytes, compared with adding a new packet or extending an existing one.
I really have to stop working on the mods, so I can sort out the tyre physics and then we can release the new graphics. So there has to be an end. And I still have a couple of important things on my list.
Anyway, is there an appropriate InSim packet that your requested data values could be squeezed into? It's always a lot easier to use some unused bytes, compared with adding a new packet or extending an existing one.
Yeah that's the thing. I'm just trying to get this mods system 'finished' so I can do the tyre physics and we can release the new graphics system.
The idea of user-defined layout objects, it just brings up so many questions, would they be uploaded like mods, or maybe defined locally instead (transferred from server to guests). But maybe the better thing is really to get to a point where we could release a track editor. Well, it's not the same thing at all, although a track editor would be the proper solution to a lot of what people actually do with layouts.
So I hope you see, it's not a bad idea or anything like that. Just that for me it's not the time to think about adding a whole new system, while I have so many new systems already in development and not yet released.
The idea of user-defined layout objects, it just brings up so many questions, would they be uploaded like mods, or maybe defined locally instead (transferred from server to guests). But maybe the better thing is really to get to a point where we could release a track editor. Well, it's not the same thing at all, although a track editor would be the proper solution to a lot of what people actually do with layouts.
So I hope you see, it's not a bad idea or anything like that. Just that for me it's not the time to think about adding a whole new system, while I have so many new systems already in development and not yet released.
Disappearing sound bug
Hello mod users,
I will need to fix this issue, where certain setups of certain mods, then driven in a certain way, can cause a physics glitch that results in a sound problem that affects all users who are within range of that vehicle. There may be a bad sound then a total loss of engine sounds.
So does anyone know of a simple way to reproduce this? If necessary, I could trawl through an MPR from a cruise server but my job would be a lot simpler if this can be reproduced on demand, or in an MPR with just the one vehicle in it. It's a lot easier to track down something in the debugger if there is less going on.
Thanks!
EDIT: I did fix this in the past for some vehicles. It was something to do with the golf cart. As it had small wheels their rotation could go wrong on remote computers with some gear ratios or final drive ratios. It was not intended by the user driving the car and it came with a graphical glitch too.
I will need to fix this issue, where certain setups of certain mods, then driven in a certain way, can cause a physics glitch that results in a sound problem that affects all users who are within range of that vehicle. There may be a bad sound then a total loss of engine sounds.
So does anyone know of a simple way to reproduce this? If necessary, I could trawl through an MPR from a cruise server but my job would be a lot simpler if this can be reproduced on demand, or in an MPR with just the one vehicle in it. It's a lot easier to track down something in the debugger if there is less going on.
Thanks!
EDIT: I did fix this in the past for some vehicles. It was something to do with the golf cart. As it had small wheels their rotation could go wrong on remote computers with some gear ratios or final drive ratios. It was not intended by the user driving the car and it came with a graphical glitch too.
Last edited by Scawen, .
FGED GREDG RDFGDR GSFDG